UNCLASSIFIED/UNLIMITED 


Click  here  to  view  PowerPoint  presentation;  Press  Esc  to  exit 


ORGANIZATION 


UK  ISTAR  Architectures  and  Capability  Management 

Dr  Jim  Wood,  Dr  Andrew  Green1,  Dr  Peter  Burge2 

Room  N 1 0 1 ,  DSTL 
St  Andrews  Road 
Malvern,  Worcs.  WR14  3PS 
UK 

jwwood@dstl.gov.uk 


ABSTRACT 

The  paper  describes  the  development  of  a  UK  ISTAR  architecture,  compliant  with  the  US  Department  of 
Defense  Architecture  Framework  (and  the  UK  MOD  AF),  and  its  application  to  ISTAR  capability 
management.  The  need  for  an  architecture  to  underpin  descriptions  of  capability  is  established,  followed 
by  a  description  of  the  process  and  tool  used  to  generate  the  architecture.  The  formal  relationship 
between  capability  and  equipments  is  discussed,  and  practical  means  to  represent  and  manage  this 
relationship  are  developed.  The  paper  concludes  with  a  description  of  the  application  of  this  methodology 
to  the  development  of  a  UK  ISTAR  capability. 


1.0  INTRODUCTION 

UK  MOD  has  adopted  a  capability-based  procurement  process.  Capability  is  expressed  principally  in  the 
form  of  Equipment.  However,  MOD  also  recognises  5  other  “Lines  of  Development”  (LODs):  personnel, 
training,  doctrine,  sustainability  and  structures  and  estates  that  also  contribute  to  Capability. 

Directors  of  Equipment  Capability  (DECs)  manage  equipment  procurement.  DEC(ISTAR)  (Intelligence  , 
Surveillance,  Target  Acquisition  and  Reconnaissance)  is  responsible  for  provision  of  equipment  to  support 
the  ISTAR  function.  DEC(ISTAR)  also  has  a  “core-DEC”  role;  this  means  that  there  are  some  ISTAR- 
related  equipment  programmes  that  he  does  not  have  direct  control  over;  these  programmes  are  managed 
by  other  DECs. 

The  challenge  facing  DEC(ISTAR)  is  to  ensure  that  UK  has  an  appropriate  ISTAR  Capability,  recognising 
that  this  will  be  achieved  not  only  by  purchase  of  ever-more  technologically-advanced  equipment,  but  also 
by  understanding  how  to  use  this  equipment  effectively,  which  may  be  achieved  by  changes  in  other 
LODs. 

The  capability  delivered  by  equipments  is  also  strongly  influenced  by  the  architecture  in  which  they  are 
employed.  Trivially,  for  example,  without  adequate  communications,  equipments  will  not  be  able  to 
deliver  their  data  to  the  user.  At  a  higher  level,  the  architecture  also  captures  how  equipments  interact  at 
both  the  technical  and  operational  levels  to  provide  capability.  This  formal  relationship  is  examined 
further  in  section  0. 

Given  the  importance  of  an  architecture  to  support  management  of  (ISTAR)  capability,  DEC(ISTAR)  has 
commissioned  the  production  of  a  UK  ISTAR  architecture  that  describes  the  ISTAR  System  of  Systems  at 
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Operational,  System  and  Technical  levels.  Section  2.0  describes  the  UK  architecture  framework,  and  the 
use  of  a  particular  tool  (ISSE)  as  a  means  to  manage  production  of  the  architecture.  The  application  of  this 
framework  and  tools  to  the  production  of  the  UK  ISTAR  architecture  is  described  in  section  3.0.  The 
integration  of  the  ISTAR  architecture  into  a  Capability  Architecture  is  discussed  in  section  4.0,  where  the 
requirements  for  a  Capability  Management  tool  are  developed,  and  a  design  for  such  a  tool  are  presented. 
Section  0  shows  the  application  of  the  Architecture  and  Capability  Architecture  to  the  development  of  a 
future  UK  ISTAR  Capability. 


2.0  ARCHITECTURE  FRAMEWORK  AND  TOOLS 

2.1  The  Ministry  of  Defence  Architecture  Framework 

Architectural  Frameworks  provide  us  with  a  mechanism  for  producing  and  exchanging  architecture 
products  in  a  consistent  fashion.  They  enable  teams  of  architects  to  exchange  specific  views  of  an 
architecture  by  labelling  them  so  that  both  parties  know  what  to  produce  and  what  to  expect.  The 
Department  of  Defence  Architectural  Framework  (DoDAF)  is  one  such  mechanism  that  has  been  widely 
adopted  over  the  past  couple  of  years.  The  UK  MOD  has  recognised  the  utility  of  DoDAF,  whilst  at  the 
same  time  noting  some  enhancements  that  will  be  necessary  to  fulfil  all  the  needs  of  UK  SMART 
(capability -based)  procurement.  This  has  led  to  the  development  of  a  UK  Architectural  Framework  named, 
unsurprisingly,  the  Ministry  of  Defence  Architecture  Framework  (MoDAF). 

MoDAF  has  a  number  of  key  additions  to  DoDAF.  Firstly  the  introduction  of  some  new  architectural 
views,  namely  Capability  Views  and  Acquisition  Views.  Both  of  these  are  targeted  at  supporting  the 
Equipment  Capability  community  providing  them  with  a  graphical  representation  of  how  capability 
requirements  are  being  met,  will  be  met  or  when  such  capability  will  be  withdrawn. 


Figure  1  Three  aspects  to  MoDAF 

Equally  important  are  the  additional  modelling  constraints  that  MoDAF  provides  to  aid  consistency.  The 
first  of  these  is  a  Reference  Model  that  constrains  the  way  in  which  we  describe  an  architecture, 
essentially  through  nodes  and  links.  Only  relationships  that  appear  in  the  reference  model  are  permitted. 
The  second  is  the  Object  Taxonomy  that  provides  a  dictionary  of  terms  that  can  be  used  in  the 
architecture.  This  ensures  that  modellers  use  consistent  terminology.  Together  these  tools  provide  us  with 
a  powerful  way  to  describe  the  MOD  system  of  systems  leading  to  an  understanding  that  will  enable 
informed  decision  making  and  fewer  integration  incidents. 
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2.2  Architecture  Tools  and  the  Need  for  a  Government  Repository 

There  are  many  tools  available  in  the  market  for  producing  architectural  views.  Some  of  these  now  purport 
to  being  MoDAF  compliant.  The  MOD  recognised  the  need  for  a  single  validated  model  of  the  UK  system 
of  systems.  As  a  result  the  Integration  Services  Support  Environment  (ISSE)  was  developed.  ISSE  is  a 
bespoke  application  built  by  LogicaCMG  and  Vega  for  the  Integration  Authority  (IA).  ISSE  is  also 
MoDAF  compliant.  ISSE  enables  the  IA  to  produce  five  types  of  models  all  inter-linked  and  stored  in  an 
Oracle  database.  Utilising  a  relational  database  enables  the  IA  to  perform  structured  queries  on  the  data 
pulling  out  for  example,  time-based  views  on  the  phased  introduction  of  a  platform’s  capability. 


Programme 

Model 


Operational  Model 


Service  Model 
or 

“Requirements 

Model” 


Deployment 

Views 


Figure  2  Five  Dimensions  to  ISSE  Models 

The  Operational  Model  describes  the  needs  of  the  business  in  military  terms.  This  model  is  system 
independent  and  justifies  the  need  for  equipment  to  support  it.  The  operational  model  shows  what 
information  is  required  by  which  military  roles  and  at  which  facilities/platforms. 

The  Service  Model  is  used  to  describe  in  a  logical  manner  the  requirement  for  equipment  to  support 
operations.  The  MOD  is  moving  towards  complimenting  existing  requirements  documentation,  or  even 
replacing  it,  with  UML  models  that  tends  to  lead  to  a  more  unambiguous  statement  of  the  requirement. 

The  Component  Model  is  where  industry  can  respond  to  the  requirement  in  the  Service  Model.  The 
linking  between  the  Component  Model  and  the  Service  Model  shows  how  requirements  are  being  met. 

The  Programme  Model  provides  the  time-based  view  of  which  programmes  are  responsible  for 
delivering  which  aspects  of  the  System  of  Systems.  It  is  linked  into  the  Service  Model  and  the  Component 
Model  thus  enabling  a  view  on  the  ‘as-is’  architecture  and  to  view  planned  future  architectures. 

All  of  the  above  Models  feature  in  the  Deployment  View  where  we  bring  together  real  architectures  built 
from  the  underlying  validated  models  using  the  viewpoint  that  MoDAF  provides.  All  of  these  models  have 
been  populated  for  the  purposes  of  developing  the  ISTAR  Architecture. 
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3.0  THE  BASELINE  UK  ISTAR  ARCHITECTURE 

The  UK  Baseline  ISTAR  Architecture  was  commissioned  by  the  Director  of  Equipment  Capability  (DEC) 
for  ISTAR  (Intelligence,  Surveillance,  Target  Acquisition  and  Reconnaissance)  in  March  2004  with 
delivery  in  June  2004.  DEC(ISTAR)’s  requirement  can  be  summarised  by  the  single  statement  “Show  me 
how  my  systems  of  interest  will  be  used  in  the  year  20 1 0”.  The  systems  used  within  the  architecture  were 
ISTAR  systems  currently  in  service  which  will  still  be  in  service  in  the  year  2010  (fielded  systems),  and 
ISTAR  systems  which,  although  still  in  procurement,  will  be  in-service  in  the  year  2010  (funded  systems). 
An  additional  part  of  the  DEC’S  requirement  was  that  the  modelling  was  to  be  undertaken  using  ISSE  and 
that  the  architectural  views  would  be  compliant  with  the  UK  MoDAF. 

The  work  was  undertaken  by  a  QinetiQ-led  team  in  partnership  with  the  IA  and  Dstl. 

3.1  Aim  and  Scope  of  the  UK  Baseline  Architecture 

3.1.1  Aim 

The  UK  Baseline  ISTAR  Architecture  project  was  designed  to  provide  DEC(ISTAR)  with  an  initial  view 
of  his  current/near-term  ISTAR  Architecture.  The  architecture  needs  to  show  how  ISTAR  assets  are 
deployed  throughout  the  command  hierarchy,  who  can  directly  access  those  assets,  what  they  are  used  for 
(where  possible)  and  how  they  are  used.  The  UK  Baseline  Architecture  is  to  encompass  the  Operational, 
System  and  Technical  views  as  defined  by  MoDAF. 

The  aim  of  the  work  can  be  expanded  to  cover  the  following  questions: 

•  Show  me  who  is  using  my  systems? 

•  Show  me  why  they  are  using  my  systems? 

•  Show  me  how  my  systems  are  organised? 

•  Show  me  what  these  systems  are  doing? 

•  Show  me  what  support  my  systems  require? 

These  statements  expand  the  scope  of  the  work  to  include  a  study  of  the  requirements  for  ISTAR  support 
to  UK  military  forces  as  well  as  a  presentation  of  the  Command  and  Information  Systems  (CIS)  required 
to  deliver  a  UK  ISTAR  Capability. 

Additionally,  it  is  envisaged  that  the  creation  of  the  UK  Baseline  ISTAR  Architecture  will  enable 
DEC(ISTAR),  and  his  staff,  to  explore  the  uses  of  architectures  and  the  potential  power  of  having  an 
ISTAR  architecture.  The  UK  Baseline  ISTAR  Architecture  will  also  be  used  as  a  starting  point  to  bring 
coherence  to  the  Integrated  Project  Teams  (within  the  Defence  Procurement  Agency)  in  how  they  use 
architectures,  and  bring  coherence  to  the  DECs  and  Customer  2  on  how  CONEMP,  CONUSE  and 
CONOPS  may  be  developed  in  the  future. 

3.1.2  Scenarios 

Given  the  drive  to  deliver  a  view  of  how  the  systems  are  used  and  integrated  into  a  military  command 
hierarchy  it  is  necessary  to  set  the  UK  Baseline  Architecture  within  a  scenario  context.  Although  the  UK 
has  a  number  of  standardised  military  scenarios  which  are  used  for  operational  analysis  studies  it  was 
deemed  that  for  this  work  a  more  generic  scenario  could  be  used  which  would  then  be  applicable  to  more 
than  one  specific  scenario  with  relatively  few  modifications.  The  generic  scenario  is  based  around  a  force- 
on-force  quasi-symmetric  warfighting  operation 
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The  Strategic  context  for  this  type  of  scenario  is  the  next  decade  or  so,  where  the  ‘western  world’  is 
opposed  by  national  state  opponents.  UK  forces  are  engaged  on  expeditionary  operations  against  the  Army 
of  a  nation  state  adversary,  operating  as  a  multinational  coalition. 

‘Quasi-symmetric’  Fighting  Operations  occur  where  this  opposition  leads  to  expeditionary  warfare  in 
which  the  UK  moves  into  a  region  and  uses  formed  forces  to  engage  in  combat  with  the  adversary,  who 
defends  himself  using  formed  forces.  Both  sides  make  use  of  broadly  similar  types  of  fighting  capability, 
but  the  UK  has  a  significant  superiority,  especially  in  the  key  capabilities  of  firepower  (Weapons)  and 
intelligence-gathering  (ISTAR).  Accordingly,  the  adversary  adapts  his  Operational  and  Tactical  Ways,  in 
order  to  win  the  campaign  politically,  accepting  defeat  or  stalemate  on  the  battlefield. 

The  UK’s  military  ends  tend  to  be  concerned  with  the  Adversary’s  occupancy  of  ground,  and  with  the 
state  or  activity  of  the  adversary’s  forces.  UK  forces  will  seek  a  successful  conclusion  to  the  campaign 
quickly  and  with  minimum  casualties,  whilst  maintaining  the  integrity  of  its  Coalition  and  the  consent  of 
the  international  community.  The  adversary  will  generally  use  a  sequence  of  military  and  non-military 
parries  to  the  UK’s  forceful  intervention  in  the  region.  These  will  be  targeted  at  the  UK’s  Operational 
vulnerabilities  (public  opinion,  coalition  cohesion,  need  for  speed,  aversion  to  casualties),  minimising 
tactical  exposure  to  the  UK’s  ISTAR  and  depth  firepower  and,  on  occasion,  seeking  to  inflict  loss  in 
contact  battles  fought  on  the  adversary’s  initiative.  Thus,  the  adversary  aims  to  keep  or  get  UK  forces  out, 
while  the  UK  forces  may  have  similar  aims,  or  may  be  seeking  to  neutralise  the  adversary  force. 

3.1.3  Military  Commands 

Another  key  factor  for  the  scope  of  the  architecture  is  the  military  command  hierarchy  and  the 
headquarters  which  are  likely  to  be  represented  within  that  hierarchy.  For  the  UK  Baseline  Architecture  a 
scope  which  included  all  deployed  headquarters  and  the  Permanent  Joint  Headquarters  was  chosen 
however,  in  order  to  reduce  the  scope  slightly  the  Special  Forces  and  Logistics  Components  were  not 
considered.  These  components  will  be  added  to  later  stages  of  the  Architecture. 

3.1.4  Military  Processes 

In  addition,  since  this  was  to  be  an  ISTAR  Architecture  the  scope  of  the  ISTAR  functions  represented 
needed  to  be  considered.  The  UK  Doctrine  uses  the  terminology  Direction,  Collection,  Processing  and 
Dissemination  to  represent  the  Intelligence  cycle.  The  UK  Baseline  Architecture  covers  all  of  these  stages 
but  stops  at  looking  at  the  processes  and  systems  used  to  generate  the  intelligence  requests,  and  at  the  use 
to  which  the  intelligence  is  put  once  it  is  passed  back  to  the  consumer. 

3.1.5  ISTAR  and  CIS  Assets 

Finally,  it  has  already  been  stated  that  UK  Baseline  Architecture  is  limited  in  scope  to  the  ISTAR  Assets 
that  are  fielded  and  funded.  However,  the  need  to  represent  CIS  is  driven  by  the  other  elements  of  the 
architectural  scope.  In  total  some  sixty  or  so  CIS  systems  needed  to  be  represented  in  order  to  complete 
the  UK  Baseline  Architecture.  These  systems  were  represented  at  a  very  high  level  of  abstraction  and  it  is 
hoped  that  future  development  of  these  models  will  be  undertaken  by  the  DECs  responsible  for  these 
systems  (mostly  the  DEC  responsible  for  Command  and  Control  and  Information  Infrastructure  -  CCII). 

3.2  Architectural  Design  Principles 

It  should  be  obvious  by  now  that  the  UK  Baseline  Architecture  is  an  instantiated  architecture  based  on  the 
architectural  design  principles  and  the  systems/architectural  components  available  to  the  chief  architect.  It 
is  therefore  necessary  to  identify  the  architectural  design  principles  used. 
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The  only  authoritative  documents  available  to  the  design  team  were  current  military  joint  and  single¬ 
service  doctrine.  These  documents  describe  a  very  conservative  view  of  the  use  of  ISTAR  assets  to 
support  operations  and  sadly  do  not  yet  reflect  some  of  the  emerging  concepts  for  the  use  and  management 
of  UK  ISTAR  assets.  However,  since  this  was  the  authoritative  document  set,  and  since  this  is  a  baseline 
architecture,  these  were  the  design  principles  used. 

In  some  places  the  doctrine  was  either  not  of  sufficient  detail,  or  incomplete,  to  explain  some  aspects  of 
the  architecture.  Where  this  was  the  case,  expert  technical  and  military  judgement  was  used  to  ‘fill  the 
gaps’. 


3.3  Modelling  the  Components 

The  components  of  the  architecture  were  modelled  using  the  Integrated  Services  Support  Environment 
(ISSE)  toolset. 

In  ISSE  the  operational  layer  describes  military  functions,  role,  resources  and  information  products.  These 
were  populated  for  each  of  the  three  main  services  (Army,  Navy  and  Royal  Air  Force)  and  for  the  Joint 
level  of  command.  Where  possible  this  data  was  validated  with  appropriate  service  lead.  From  this  data  an 
operational  deployment  diagram  was  created. 

The  system  level  is  populated  using  logical  service  models  and  physical  component  models.  Given  the 
broad  scope  of  the  UK  Baseline  Architecture  project,  and  the  concentration  on  ‘who  does  what  functions 
with  what  systems?’  it  was  only  possible  to  create  the  complete  baseline  architecture  using  logical  service 
models  of  the  ISTAR  and  CIS  assets.  It  was  largely  only  possible  to  model  the  systems  from  their 
requirements,  rather  than  actual  system  designs.  The  reason  for  this  is  that  system  design  documentation 
largely  resides  within  the  hands  of  those  companies  which  manufacture  the  systems  and  that  these 
documents  are  often  company  proprietary.  In  time,  the  work  of  the  ISTAR  Architectures  community  will 
need  to  encompass  the  modelling  of  systems  ‘as  they  are’  rather  than  ‘as  they  were  intended  to  be’  but  for 
this  to  happen  there  will  need  to  be  greater  openness  about  system  design  within  the  defence  industry. 

The  systems  are  modelled  according  to  the  services  that  they  provide,  the  functions  which  they  support 
and  the  information  products  which  they  exchange  (either  internally  or  externally). 

For  the  first  release  of  the  UK  Baseline  ISTAR  Architecture  there  has  been  no  technical  architecture 
provided. 

3.4  Building  the  Architecture 

Once  the  component  models  and  architectural  design  principles  are  understood  architectural  instantiation 
can  be  created.  In  ISSE  terms  deploying  the  components  according  to  the  architectural  design  principles 
creates  the  architectural  instantiation.  This  is  the  role  of  the  chief  architect.  Physically,  within  ISSE,  this  is 
done  by  creating  UML  sequence  diagrams  that  can  then  be  used  to  create  UML  collaboration  diagrams. 
From  these  collaboration  diagrams  various  of  the  matrix  views  of  information  exchange  products,  etc.  can 
then  be  generated. 

3.5  Architectural  Views 

Two  sets  of  architectural  views  were  generated  from  the  UK  Baseline  Architecture  dataset.  The  first  was 
the  broad,  but  shallow  UK  Baseline  Architecture  while  the  second  was  a  more  detailed  case  study  that 
looked  at  specific  cueing  interactions  within  a  limited  subset  of  the  UK  ISTAR  Inventory.  For  each  of 
these  circumstances,  a  difference  set  of  MoDAF  views  was  generated. 
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For  the  broad  UK  Baseline  Architecture  the  views  generated  were:  AV-1,  AV-2,  OV-1,  OV-2,  OV-3,  OV- 
5,  SV-1,  SV-2,  SV-3,  SV-5.  For  the  more  limited  cross-cueing  case  study  the  views  generated  were:  AV- 
1,  AV-2,  OV-1,  OV-2,  OV-3,  OV-5,  OV-6c,  SV-1,  SV-2,  SV-3,  SV-4,  SV-5.  These  views  can  be  directly 
read-across  to  the  corresponding  DoDAF  views. 

3.6  Completeness  of  the  UK  Baseline  Architecture 

The  UK  Baseline  Architecture  is  by  no  means  a  complete  ISTAR  Architectural  description  and  there  are  a 
number  of  significant  steps  that  still  need  to  be  achieved  before  realising  a  complete  ISTAR  Architectural 
description. 

The  UK  Baseline  Architecture  (or  more  specifically  the  ISSE  repository  that  undeipins  the  architecture) 
contains  logical  service  models  for  all  ISTAR  Assets  that  are  fielded  and  funded  in  2010.  However,  many 
of  these  models  are  at  a  relatively  high  level  of  abstraction  (layer  5  in  ISSE-speak).  There  is  clearly  a 
significant  amount  of  work  that  needs  to  be  done  in  order  to  model  all  the  assets  to  the  same  level  of 
abstraction. 

3.7  Next  Steps  for  UK  Architectural  Studies 

The  UK  Baseline  Architecture  is  essentially  an  instantiated  architecture  representing  the  architectural 
design  principles  appropriate  for  2004  but  with  a  set  of  components  which  are  suitable  for  the  2010 
timeframe.  Given  the  step-change  in  the  UK  ISTAR  Capability  which  will  occur  in  this  timeframe  there 
clearly  need  to  be  more  thought  given  to  the  architectural  design  principles.  There  is  planned  follow-on 
work  to  determine  the  appropriate  UK  ISTAR  Architectural  Design  Principles  which  support 
DEC(ISTAR)’s  vision  of  how  ISTAR  will  be  managed  in  the  year  2020.  The  design  principles  are  key  to 
achieving  a  UK  ISTAR  Capability  which  fully  realises  the  potential  of  the  new  generation  of  ISTAR 
assets. 

In  addition  to  the  key  work  on  architectural  design  principles,  the  current  UK  Baseline  Architecture  will 
be  used  to  prototype  the  use  of  ISTAR  Architectures  in  supporting  both  the  UK  Capability  Audit  process 
as  well  as  the  UK  Capability  Architecture  work  described  in  this  paper.  It  is  vital  to  obtain  a  good 
understanding  of  how  the  ISTAR  Architectural  Design  Principles  enable  the  assets  to  fulfil  their  capability 
goals,  and  where  the  ISTAR  Architectural  Design  Principles  limit  the  utility  of  the  assets  being  procured 
by  the  UK  Ministry  of  Defence. 

In  order  to  achieve  both  of  these  visions  the  UK  must  form  both  an  authoritative  ISTAR  Concepts  forum 
and  have  detailed  systems  models  available  in  order  to  be  able  to  model  architectural  instantiations. 

In  the  short-term  the  UK  Baseline  Architecture  will  be  rolled  out  across  the  DEC  and  the  IPTs  to  make 
them  more  architecturally  aware  and  to  help  create  dialogue  and  understand  the  true  DEC(ISTAR) 
requirement  for  architectures.  DEC(ISTAR)  is  also  keen  to  engage  with  the  defence  industry  to  support 
the  development  of  the  architecture  especially  in  the  area  of  open  standards  and  formats  to  enable  a  more 
enhanced  ISTAR  capability. 


4.0  THE  CAPABILITY  ARCHITECTURE 

4.1  The  Purpose  of  the  Capability  Architecture 

The  aim  of  the  capability  architecture  is  to  assist  DEC(ISTAR)  in  the  management  of  his  equipment 
programme  (EP),  by  enabling  him  to  understand: 

•  The  need  for  new  ISTAR  equipment 
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•  The  context  within  which  the  equipment  must  sit 

•  How  ISTAR  equipment  relates  to  other  equipments 


4.2  The  Formal  Relationship  between  Capability  and  Architecture 

The  aim  of  this  section  is  to  derive  the  formal  relationship  between  architectures  and  capability 
management.  This  will  be  used  in  later  sections  to  assess  existing  approaches  to  capability  modelling  and 
as  the  basis  for  a  proposal  for  a  capability  architecture. 

Capability  is  defined  to  be 

“The  set  of  equipment  (systems),  men  and  procedures  that  deliver  a  capability  need  or  component 
of  military  force” 


Therefore  a  capability  model  must  represent 


•  The  capability  requirements,  expressed  as  capability  need  or  a  component  of  military  effect,  in 
combination  with 

•  Solutions,  which  includes  equipment  (captured  in  the  EP  portfolio),  men  and  procedures,  which, 
as  discussed  above  implies  a  need  for  a  representation  of  architecture  in  its  most  complete  sense. 


HLOA  Command  and  Inform 


Decomposes  into 


e.g.  Conduct  surveillance  to  support  IPB 


High  level  Military  Tasks 


e.g.  Conduct  surveillance  to  support  IPB 


Decompose  into 


Capability  Requirements 


e.g.  find,  locate  and  monitor  military  eqmt. 


e.g.  locate  military  equipment, 

e.g.  SIGINT-  detect  communications  signals 
IMINT  -  detect  military  vehicles 


Figure  3  Capability  Requirement  Decomposition 

High  level  [ISTAR]  capability  requirements  can  be  decomposed  (through  a  number  of  stages)  into 
particular  information  types,  which  can  then  be  associated  with  ISTAR  equipments,  as  shown  in  Figure  3. 
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Figure  4  Equipment  provides  capability  through  architecture 


In  reality,  all  levels  of  this  decomposition  are  one  to  many,  and,  as  noted  above,  equipments  can  only  be 
used  to  meet  capability  requirements  when  they  are  embedded  in  an  architecture,  as  shown  in  Figure  4. 
This  illustrates  the  complexity  of  the  capability  management  problem,  but  it  is  possible  to  visualise  (in 
Figure  5)  two  simple  “queries”  that  must  be  supported  by  the  capability  model. 

The  query  illustrated  on  the  left  is  “Show  me  which  equipments  provide  capability  X”  and  the  query  on 
the  right  is  “Show  me  which  capabilities  equipment  Y  contributes  to”.  In  both  cases,  the  query  is 
supplemented  by  the  condition  “subject  to  the  architecture”. 


Figure  5  Capability  Queries 

Figure  3  describes  one  way  in  which  a  capability  taxonomy  may  be  derived,  based  on  military  tasks.  There 
are  alternatives,  such  as: 
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•  A  taxonomy  based  on  commander’s  information  requirements.  These  tend  to  be  strongly  related 
to  scenarios,  but  this  approach  does  provide  a  strong  linkage  to  operational  need  for  ISTAR 
capability 

•  A  decomposition  based  on  environment  (Land,  Sea,  Air. . .),  further  decomposed  into  Deep,  Close 
Rear...  .  This  is  the  approach  adopted  by  DEC(ISTAR)  in  his  capability  audit,  and  matches  well 
to  the  organisational  structure  used  to  manage  the  EP 

•  ATP-61  “Reconnaissance  and  Surveillance  Support  to  Allied  Joint  Operations”  can  be  used  to 
derive  a  taxonomy  based  on  level  of  command  (Strategic,  Operational,  Tactical)  followed  by  tasks 
(Intelligence  Preparation  of  the  Battlespace,  Identify  enemy  ORBAT...).  This  is  operationally 
grounded,  but  lacks  the  scenario  context. 

From  this,  we  can  conclude  that  different  users  have  different  needs  for  a  capability  taxonomy,  and 
therefore  the  capability  architecture  must  be  able  to  support  different  taxonomies. 

4.2.1  Summary  of  Requirement 

The  Capability  Architecture  will  capture  how  equipments  provide  capability,  supported  by  the  ISTAR 
architectures,  and  taking  into  account  other  Lines  Of  Development.  This  must  be  achieved  in  a  “tool”  that 
is  useable  by  both  DEC  staff  and  the  technical  community.  It  must  be  capable  of  capturing  the  architecture 
in  the  link  between  equipment  and  capability,  and  the  capability  taxonomy  is  itself  fluid. 

4.3  A  Pragmatic  Approach 

The  relation  between  capability  and  equipment  is  captured  succinctly  in  Figure  6. 


Capability 


Condition 


Equipment 


Figure  6  Relation  between  Capability  and  Equipment 

In  this  diagram,  the  “crows  foot”  represents  a  “many  to  one”  relationship.  “Condition”  captures  the  issues 
described  in  the  preceding  section.  The  kinds  of  relationships  covered  by  Condition  include: 

•  Scenario:  the  scenario  setting  within  which  an  equipment  is  providing  a  capability 

•  Equipment:  the  other  equipment  that  is  required  for  the  equipment  under  consideration  to  be  able 
to  provide  the  capability.  (For  example,  Equipment  A  may  need  to  be  cued  by  Equipment  B 
before  it  can  perform  certain  tasks) 

•  Means  of  Use  (CONEMP):  A  reference  to  documents  describing  how  an  equipment  is  expected  to 
be  used. 

•  Connectivity  in  Logical,  Technical  and  Physical  terms.  Essentially,  this  is  a  link  into  (a  fragment 
of)  the  ISTAR  architecture,  that  gives  assurance  that  the  equipment  will  be  able  to  provide  the 
capability  described. 

•  Architecture  Metrics:  This  describes  assumptions  or  conditions  on  the  architecture  that  must  be 
met  to  provide  the  capability.  For  example,  it  may  be  predicated  on  a  certain  bandwidth  or 
timeliness  of  communications. 
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4.4  Implementation  Considerations 

Figure  6  shows  how  capability  (captured  in  a  suitable  taxonomy)  can  be  related  to  equipment  that 
contributes  to  that  capability,  subject  to  certain  conditions.  This  structure  is  able  to  support  the  kinds  of 
queries  described  in  section  0  (what  equipment  provides  capability  X,  and  how  is  capability  Y  provided?). 
And,  if  the  “Conditions”  data  is  suitably  structured,  it  will  also  be  able  to 

•  Qualify  the  results  of  these  queries.  For  example  “Eqpt  A  provides  the  capability  to  identify 
targets,  provided  it  is  cued  by  Eqpt  B,  and  that  cross-cueing  procedures  are  in  place,  and  that 
suitable  communications  links  are  in  place  between  Eqpt  B  and  Eqpt  A”.  The  whole  of  the 
“provided”  clause  would  be  captured  in  Conditions 

•  Track  the  effect  of  any  change  in  the  Conditions.  For  example,  if  the  provision  of  communications 
between  Eqpt  A  and  B  is  no  longer  assured  (because  of  changes  in  a  project  providing 
communications  infrastructure,  perhaps),  then  the  capability  of  Eqpt  A  to  identify  targets  should 
be  reassessed. 

However,  these  kinds  of  queries  will  only  be  possible  if  the  Conditions  data  is  well  structured.  If  this  is  not 
the  case  -  for  example,  if  all  the  Conditions  are  captured  in  a  free  format  text  document  (or  documents),  it 
will  be  hard,  if  not  impossible,  to  track  changes  automatically.  On  the  other  hand,  trying  to  design  a  formal 
database  structure  in  which  all  possible  Conditions  are  rigidly  parameterised  is  probably  not  practicable,  as 
not  all  Conditions  will  apply  in  all  cases,  and  even  when  there  is  a  common  set  of  Conditions,  they  may  be 
parameterised  in  different  ways. 

Therefore,  there  is  a  need  for  a  flexible  tool  that  allows  users  to  capture  what  is  appropriate,  but  not  so 
flexible  that  different  users  use  different  ways  to  model  capability.  Table  1  summarises  the  benefits  and 
shortcomings  of  different  types  of  tool  that  could  be  used  to  support  the  capability  architecture. 


Table  1  Comparison  of  tool  features  to  support  capability  architecture 


Tool  Type 

Comments 

Relational  Database 
(e.g.  Access) 

Highly  structured  data.  Large  upfront  investment  to  design 
and  agree  the  relationships  and  attributes  for  Conditions. 

Strong  rules  to  ensure  valid  data  entry  -  may  over-constrain 
users.  Queries  need  to  be  designed  by  experienced  user. 

Spreadsheet  (e.g.  Excel) 

Relatively  flexible  with  respect  to  changing  attributes.  Hard 
to  capture  complex  relationships,  especially  if  these  evolve. 
Easy  to  query  and  visualise  data,  provided  it  is  reasonably 
well  formatted. 

Free  text  (e.g.  Word) 

Very  easy  data  entry.  Hard  to  enforce  commonality  of  data 
entry.  Templates  can  help,  but  reliant  on  user  to  obey 
template  rules.  Very  hard  to  query. 

Semantic  Web 

Supports  flexible  data  structures.  Data  structure  is  “self¬ 
describing”.  Queries  can  be  constructed  based  on  this. 

RTO-MP-IST-042 


5  - 11 


UNCLASSIFIED/UNLIMITED 


UNCLASSIFIED/UNLIMITED 


UK  ISTAR  Architectures  and  Capability  Management 


ORGANIZATION 


A  strong  driver  for  the  development  of  Semantic  web  technology  is  a  desire  for  improved  interoperability 
and  information  exploitation  across  communities.  This  is  achieved  through  the  use  of  extensible  Markupo 
Language  (XML),  the  Resource  Description  Framework  (RDF)  and  the  Web  Ontology  Language  (OWL). 
This  removes  the  need  for  a  “hard-coded”  data  model,  in  that  the  definitions  of,  and  relations  between, 
data  entities  are  described  in  the  data  itself.  In  the  author’s  assessment,  Semantic  Web  technology  will  not, 
in  the  foreseeable  future  at  least,  provide  information  interoperability  across  all  domains  (ultimately,  the 
“root”  definitions  and  relationships  must  be  hard-coded  into  applications).  However,  within  defined 
communities,  these  basic  definitions  can  be  agreed,  and  then  Semantic  Web  technology  can  be  exploited. 
It  is  suggested  that  Capability  Architecture  forms  such  a  community,  and  that  Semantic  Web  is,  therefore 
an  appropriate  enabler.  It  is  expected  that  Semantic  Web  technology  will  allow  users  to  express  facts  about 
capability  (including  “Conditions”)  in  a  way  that  can  be  queried  automatically,  without  having  to  be 
dogmatic  about  the  way  in  which  users  choose  to  represent  Capability. 

In  summary,  given  the  overall  requirements,  and  the  complications  implied  by  the  many  potential 
Conditions  linking  equipment  to  Capability,  Semantic  Web  appears  to  be  the  most  promising  technology 
to  capture  the  Capability  Architecture.  An  initial  implementation  of  the  capability  architecture  will  be 
undertaken  by  December  2004,  which  will  test  this  assertion. 

4.5  Application 

DEC(ISTAR)  is  currently  formulating  plans  for  a  new  capability.  At  the  unclassified  level,  certain  features 
of  this  capability  are  listed  below: 

•  There  is  a  requirement  for  concurrency  in  3  theatres. 

•  The  collection  area  covers  close,  deep  and  wide  area:  up  to  a  maximum  of  X  km  x  X  km. 

•  Able  to  carry  out  surveillance  of  collection  area  24/7  in  all  weathers  for  30  days. 

•  The  collection  area  cannot  be  overtly  entered  during  peacetime. 

•  Within  the  collection  area,  the  system  will  be  capable  of  detecting  groups  of  moving  and 
stationary  objects 

•  The  system  will  be  able  to  carry  out  persistent  watch  or  tracking  of  a  certain  number  of  ‘focused’ 
areas  within  xx  minutes  for  up  to  xx  hours. 

•  Within  the  focused  areas,  the  system  will  be  capable  of  detecting  and  tracking  small  vehicles  in  all 
weathers. 

The  capability  architecture  can  be  used  to  support  the  analysis  required  to  scope  potential  solutions: 

Figure  7  shows  existing  equipment  solutions  in  a  “technical  ability”  space.  The  dimensions  of  this  space 
include  spatial  and  spectral  resolution,  phenomenology  (SIGINT,  HUMINT  etc.),  area  covered  etc.  From 
this  it  can  be  seen  that  there  are  certain  shortfalls  in  technical  ability  (the  areas  coloured  pink  in  the 
figure.) 
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Figure  7  Equipment  Technical  Capability 

However,  the  technical  ability  analysis  is  only  a  part  of  the  process.  For  example: 

•  As  shown,  it  effectively  only  considers  each  equipment  in  isolation.  It  may  be  that  two  sensors 
can  be  used  to  meet  a  particular  technical  requirement  (e.g.  area  scan  by  one  sensor,  used  to  cue 
another  sensor  with  a  smaller  field  of  view) 

•  It  does  not  consider  the  tasking  of  the  sensors,  nor  processing  or  dissemination  of  the  data  that  is 
received. 

We  thus  need  a  further  “architectural”  analysis  that  takes  these  factors  into  account.  This  is  shown 
conceptually  in  Figure  8.  In  this  diagram,  green  lines  represent  linkages  which  can  be  instantiated,  while 
those  in  red  represent  architectural  gaps.  This  diagram  can  be  viewed  from  a  number  of  different 
architectural  perspectives.  For  example,  if  we  take  an  “operational”  view,  then  the  red  lines  represent  a 
lack  of  doctrine;  for  example  it  may  that  procedures  for  cross-tasking  of  sensors  do  not  exist.  An 
alternative  is  a  technical  view,  where  the  red  links  represent  areas  where,  for  example,  incompatible 
technical  standards  are  in  use,  which  would  mean  that  the  link  could  not  be  instantiated. 

Therefore,  the  process  of  developing  a  new  capability  is  multi-faceted:  it  is  not  sufficient  to  capture  pure 
technical  ability  of  sensors;  all  aspects  (operational  through  to  technical)  of  the  capability  must  be 
considered.  The  capability  architecture  provides  a  framework  for  this  analysis. 


Figure  8  Architecture  Considerations 
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5.0  CONCLUSIONS 

Management  of  Capability  lies  at  the  heart  of  DEC(ISTAR)’s  business,  but  it  is  a  complex  problem,  and 
much  more  than  simply  managing  equipment  procurement.  There  are  initiatives  ongoing  that  attempt  to 
address  Capability  Management,  but  there  is  currently  no  single  definitive  model. 

The  UK  ISTAR  Architecture  is  an  integral  part  of  the  Capability  Architecture,  as  it  relates  Equipment  to 
Capability.  This  technical  relationship  is  complex,  and  the  paper  has  identified  a  pragmatic  approach  to 
resolving  this  complexity.  The  proposed  supporting  technology  (Semantic  Web)  will  enable  an 
incremental  approach  to  development  of  the  Capability  Architecture  to  be  undertaken. 

©  British  Crown  Copyright  and  QinetiQ  Ltd  2004.  Published  with  the  permission  of  the  Controller  HMSO 
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INFORMATION  SYSTEMS  TECHNOLOGY  PANEL 
SYMPOSIUM 

"BUILDING  COALITION  CAPABILITIES  AND  C4ISR 
ARCHITECTURES" 


Aim  and  Outline 

•  Aim: 

-  To  describe  the  development  of  a  UK  ISTAR  architecture, 
and  its  application  to  capability  management 

•  Outline 

-  Introduction  to  Problem 

-  Description  of  Architectural  Approach 

-  Description  of  UK  ISTAR  Architecture 

-  Application  to  Capability  Management 
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Introduction  -  the  problem 

•  Procurement  of  Capability 

-  The  set  of  equipment  (systems),  men  and  procedures 
that  deliver  a  component  of  military  effect 

•  ISTAR  Capability  depends  on 

-  Supporting  infrastructure 

•  C4I 

-  System  interactions 

•  ISTAR  “System  of  Systems” 

-  The  way  in  which  systems  are  used 

•  concepts  and  doctrine 


How  do  we  record  and,  manage  these  interactions?. 


dstl 
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The  need  for  the  ISTAR  Architecture 

"Show  me  how  my  systems  of  interest  will  be  used" 

•  Show  me  who  is  using  my  systems? 

-  The  command  hierarchy  which  generates  Info  Requirements 

•  Show  me  why  they  are  using  my  systems? 

-  The  IRs  which  the  command  hierarchy  generates 

•  Show  me  how  my  systems  are  organised 

-  The  management  arrangements  and  tactics 

•  Show  me  what  these  systems  are  doing 

-  Typical  tasks 

•  Show  me  what  support  my  systems  require 

-  The  necessary  infrastructure 
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Architectural  Approach 
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MOD  Architecture  Framework  -  MoDAF 


Reference  Model 


-  Rules  for  construction 
of  architecture 

Object  Taxonomy 

-  Dictionary  of  terms; 
consistent  terminology 

MoDAF  Views 

-  As  per  DODAF,  with 
additions 
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Framework  Implementation  -  ISSE 


•  Integration  Services  Support  Environment 


-  Operational  Model 

•  Needs  of  business  in  military  terms 

-  Service  Model 

•  Requirement  for  equipment  to 
support  operational  requirements 

-  Component  Model 

•  Industry  response  to  requirement 

-  Deployment  View 

•  Against  a  scenario 

-  Programme  Model 

•  Programmes  over  time 


jf 
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Modelling  Dimensions 


Modelling  Palette 


Operational  Models 


System/Service  L^omponent 
Models  i  Models 


Scenario  Based 
Physical 
I  STAR 
Architecture 
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Building  the  ISTAR  Architecture 


•  Major  stages: 

-  Understand  the  need  for  the  Architecture 

•  As  previously  described 

-  Scope  the  architecture  (components) 

•  Initially,  systems  in-service  in  2010 

•  Breadth,  not  depth 

-  Determine  the  appropriate  design  principles 

-  Construct  the  operational  views  (military  business) 

-  Construct  the  system  and  technical  views 
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Modelling  Layers 
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Modelling  Complete 


Operational  Layer 


Business  Layer 


Applications  Layer 


Network  and  Comms  Laye 


2010 

Service 

Architecture 
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What  design  principles? 

•  Only  authoritative  design  principles  are  doctrine 

•  Problem: 

-  Doctrine  is  not  consistent 

-  Doctrine  is  not  detailed  enough  (incomplete) 

-  Doctrine  ‘glosses  over’  complicated  issues 

•  Solution: 

-  Use  foundation  of  previous  research  work  as 
design  principles 

•  Conclusion: 

-  Architectural  definition  can  be  used  to  identify 
missing  doctrine/specification 
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Application  to  Capability  Management 

•  Relation  between  capability  and  equipment 

-  Complex 

-  Related  to  architecture 

•  Implementation 

•  Example 
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Capability  Queries 


High  level  Military  Tasks 
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Capability  Architecture 

Capability  - ^  Condition 


•  Condition: 

-  Scenario 

-  Other  equipment 

-  Means  of  Use  (CONEMP) 

-  Connectivity 

•  Logical 

•  Technical 


•  Physical 

Architecture  Metrics 


•  Performance 
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Capturing  Conditions 

•  Relational  Database 

-  Structured;  upfront  design  effort;  strong  data  validation 
rules;  complex  query  design 

•  Spreadsheet 

-  Flexible  design;  hard  to  capture  complex  relationships; 
flexible  visualisation 


•  Free  text 


-  Easy  data  entry;  hard  to  enforce  rules/consistency;  very 
hard  to  query 


•  “Semantic  Web”  approach 


-  Flexible  data  structures;  “self-describing”  data;  information 
communities;  queries? 
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Example 


Future  Work 


•  Deepen  the  representation  of  system  descriptions 

-  Capture  the  technical  architecture  characteristics 

•  NATO  Interoperable  ISR  Architecture  -  NIIA 

-  Analysis  of  architectural  issues 

•  Broaden  the  architecture 

-  Modelling  future  systems  -  “ISTAR  2020” 

-  Engage  with  other  functional  areas 

•  Engage  with  industry 

-  Open  standards  and  formats 


Further  development  of  the  capability  model 
-  Capability  audit  Spring  2005 
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Conclusions 


•  UK  ISTAR  Architecture 

-  Rigorous  approach 

-  Formal  tool  support 

-  DODAF/MODAF  Compliant 

•  Capability  Management 

-  Complex  problem 

-  Closely  linked  to  architecture 

-  Pragmatic  approach,  to  be  tested  and  extended 
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